fix(composer): show project skills in menus - #7909
Conversation
Co-authored-by: maria <254055478+maria-rcks@users.noreply.github.com>
Thread transfer impact✅ Thread transfer remains within every enforced ceiling.
Baseline: Scenario and decoded snapshot size10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.
Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed. |
There was a problem hiding this comment.
One finding: the new slash-command branch of isComposerMenuLoading reaches an empty-state copy path in ComposerCommandMenu that only special-cases the skill trigger, so a pending project-skills query renders file-search copy in the / menu.
Posted via Macroscope — UI Consistency
ApprovabilityVerdict: Not approved Macroscope's review found this PR not approvable — This XL PR introduces workspace-scoped provider discovery, new provider probes, registry caching/invalidation, and cross-platform menu/timeline behavior, with meaningful concurrency and external-process side effects. It also changes You can add or adjust custom eligibility rules. Learn more. |
Co-authored-by: maria <254055478+maria-rcks@users.noreply.github.com>
Co-authored-by: maria <254055478+maria-rcks@users.noreply.github.com>
Co-authored-by: Utkarsh Patil <73941998+UtkarshUsername@users.noreply.github.com>
There was a problem hiding this comment.
One finding: the composer's new cwd-scoped skill list is not mirrored by the timeline's skill chip renderer, so project-scoped skills render inconsistently between the composer and the sent message.
Posted via Macroscope — UI Consistency
| const selectedProviderSkills = selectedProviderStatus | ||
| ? resolveProviderSkillsForCwd(selectedProviderStatus, gitCwd) | ||
| : []; | ||
| const selectedProviderSlashCommands = selectedProviderStatus | ||
| ? resolveProviderSlashCommandsForCwd(selectedProviderStatus, gitCwd) | ||
| : []; |
There was a problem hiding this comment.
The composer now resolves skills from the workspace snapshot for gitCwd, but the timeline chip renderer still reads the machine snapshot: ChatView.tsx passes skills={activeProviderStatus?.skills ?? EMPTY_PROVIDER_SKILLS} (line 6660) into MessagesTimeline, and SkillInlineText drops any $name it cannot find in that list. A project-only skill picked here therefore shows as a chip in ComposerPromptEditor and then as raw $name text once the message is sent — the same token rendered two different ways in one view.
Suggest resolving the timeline list the same way, e.g. skills={activeProviderStatus ? resolveProviderSkillsForCwd(activeProviderStatus, gitCwd) : EMPTY_PROVIDER_SKILLS} in ChatView.tsx (gitCwd is already in scope there).
Posted via Macroscope — UI Consistency
There was a problem hiding this comment.
fixed in 48e7493: the sent-message timeline now resolves skills from the same cwd-scoped catalog as the composer.
There was a problem hiding this comment.
Effect service conventions review: one finding on error construction in the new Codex snapshotForCwd wrapper. The rest of the change (provider-owned per-instance+cwd snapshot cache, machine snapshot preserved as fallback, registry dependency taken from the environment, driver snapshotForCwd SPI) matches the conventions.
Posted via Macroscope — Effect Service Conventions
Co-authored-by: Utkarsh Patil <73941998+UtkarshUsername@users.noreply.github.com>
Co-authored-by: Utkarsh Patil <73941998+UtkarshUsername@users.noreply.github.com>
There was a problem hiding this comment.
One finding: the new ProviderRegistryLive.refreshWorkspaceSnapshot orchestration (per-instance+cwd cache dedupe, publish on change, stale-instance rejection, clearing cwd catalogs on instance rebuild) has no focused test. Everything else in the provider-scoped snapshot work looks consistent with the conventions — driver-owned snapshotForCwd probes, machine snapshot preserved as fallback, scoped data attached inside a single atomic Ref.modify, and workspaceSnapshots stripped from the on-disk cache.
Posted via Macroscope — Effect Service Conventions
| return yield* Ref.get(providersRef); | ||
| }); | ||
|
|
||
| const refreshWorkspaceSnapshot = Effect.fn("refreshWorkspaceSnapshot")(function* (input: { |
There was a problem hiding this comment.
This is new backend behavior with several non-obvious invariants — dedupe by instanceId + cwd, publish only when the snapshot list actually changes, drop results from a stale ProviderInstance, and the rebuild path above (L597-L612) clearing workspaceSnapshots — but the only new registry test covers the pure upsertProviderWorkspaceSnapshot helper. Consider adding a focused ProviderRegistryLive test using the existing harness in ProviderRegistry.test.ts (fake ProviderInstance with snapshotForCwd) that asserts at least: a scoped probe is cached and published for one cwd without touching another cwd's menus or the machine snapshot, and an instance rebuild clears the cached cwd catalogs.
Posted via Macroscope — Effect Service Conventions
There was a problem hiding this comment.
fixed in 236bb1f: ProviderRegistryLive now has focused coverage for publish, cwd dedupe, machine snapshot preservation, and rebuild invalidation.
Co-authored-by: Utkarsh Patil <73941998+UtkarshUsername@users.noreply.github.com>
# Conflicts: # apps/web/src/components/chat/ChatComposer.tsx # packages/client-runtime/src/providerSkills.test.ts # packages/client-runtime/src/providerSkills.ts
Co-authored-by: Utkarsh Patil <73941998+UtkarshUsername@users.noreply.github.com>
There was a problem hiding this comment.
Effect service conventions review: three findings, all on the new snapshotForCwd wiring for post-session cwd catalog refreshes.
Posted via Macroscope — Effect Service Conventions
Co-authored-by: Utkarsh Patil <73941998+UtkarshUsername@users.noreply.github.com>
There was a problem hiding this comment.
One finding: the OpenCode cwd catalog refresh reuses the full provider/model/agent inventory probe instead of a skills-only query. Codex, Claude, and the registry/rebuild handling look consistent with the conventions, and the previously missing ProviderRegistryLive coverage for refreshWorkspaceSnapshot is now present.
Posted via Macroscope — Effect Service Conventions
Co-authored-by: Utkarsh Patil <73941998+UtkarshUsername@users.noreply.github.com>
Co-authored-by: Utkarsh Patil <73941998+UtkarshUsername@users.noreply.github.com>
Co-authored-by: Utkarsh Patil <73941998+UtkarshUsername@users.noreply.github.com>
There was a problem hiding this comment.
One finding on the Claude cwd catalog path; the Codex/OpenCode/registry items from earlier runs look addressed.
Posted via Macroscope — Effect Service Conventions
Co-authored-by: Utkarsh Patil <73941998+UtkarshUsername@users.noreply.github.com>
Co-authored-by: maria <254055478+maria-rcks@users.noreply.github.com>
There was a problem hiding this comment.
One finding on the new refreshWorkspaceSnapshot cache-admission rule. The narrow cwd probes (Codex skills/list, Claude capabilities+skills, OpenCode skills-only), the stale-instance rejection, the atomic Ref.modify, and the rebuild-clears-and-publishes path all look correct.
Posted via Macroscope — Effect Service Conventions
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 78ba0cc. Configure here.
Co-authored-by: maria <254055478+maria-rcks@users.noreply.github.com>
There was a problem hiding this comment.
One finding on the workspace-snapshot admission guard in ProviderRegistry.refreshWorkspaceSnapshot.
Posted via Macroscope — Effect Service Conventions
Co-authored-by: maria <254055478+maria-rcks@users.noreply.github.com>

problem
the composer only had a machine-level provider snapshot, so project/worktree skills could be missing from
/and$even though the provider loaded them correctly when a session started from that cwd.fix
this removes the generic filesystem discovery rpc from the earlier version. provider adapters remain authoritative for discovery.
testing
SKILL.mdui
no layout changes. this changes the catalog backing the existing
/and$menus.model:
gpt-5.6-solharness: Hermes Agent
request provenance
Note
Show workspace-scoped project skills and slash commands in composer menus
workspaceSnapshotstoServerProviderschema in server.ts to hold per-cwd skills and slash commands.snapshotForCwdfor Claude, Codex, and OpenCode drivers to probe and return skills for a specific directory.refreshWorkspaceSnapshottoProviderRegistryto asynchronously cache per-cwd snapshots, triggered byProviderCommandReactorduring session start.resolveProviderSkillsForCwd, falling back to machine-level data if no snapshot exists.ProviderRegistryLive.writeProviderStatusCachein ProviderRegistry.ts stripsworkspaceSnapshotsbefore persisting to disk; workspace skills are re-probed on server restart rather than loaded from cache.Macroscope summarized 429c5fe.
Note
Medium Risk
Touches provider registry caching, session-start probes, and composer catalogs. Workspace snapshots are volatile and cwd probes spawn extra provider processes, so races or failed probes can leave menus on machine-level skills.
Overview
Composer menus can now show project/worktree skills and slash commands, not only the machine-level provider snapshot.
After a provider session starts (or is reused),
ProviderCommandReactorforksrefreshWorkspaceSnapshot. Drivers (Claude,Codex,OpenCode) implementsnapshotForCwdto probe only the cwd catalog, which the registry caches onServerProvider.workspaceSnapshots(bounded, not persisted, cleared on instance rebuild, single-flighted). Clients resolve viaresolveProviderSkillsForCwd/resolveProviderSlashCommandsForCwdin web and mobile composers and timelines.Pending or missing cwd snapshots keep the machine catalog. OpenCode skill-only probes now fail visibly instead of returning an empty list.
Reviewed by Cursor Bugbot for commit 429c5fe. Bugbot is set up for automated code reviews on this repo. Configure here.